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ABSTBACT 

A prograa fias developed to ase the PLATO IV systea of 
the Oniversity of Illinois to help students solve typical prograaing 
probleas* The prograa tries to approxiaate a near* ideal situation in 
ffhich each student receives correction of logical errors and cooaents 
on good prograaing practice as he goes along in a one-on-one tutorial 
environaent. The tutor prograa utilizes an ABD-OB graph as a 
representation of all reasonably correct approaches to the particular 
problea, as veil as aany of the wrong approaches introductory 
students are likely to attempt. The coaputer-assisted instruction 
prograa gives students the personal attention they need for learning 
the problea solving of coapoter prograas. (BH) 
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Introduction 
t 

Beginning with the work of Dijlcstra [2], there has been a growing 
interest in the conputing field in the use of proper program structure 
in the solution of prograoming problems. Considerations of ease of 
debugging and program maintainability place increasing importance on 
teaching good prograu structure as an aid to problem solution. 

Unfortunately, as Gries[6] has noted, ^ile prograaaing is essen* 
tially a problem solving activity, introductory programming courses 
typically concern themselves with the syntax of a particiilar program- 
ming language, and a few more or less relevant applications, but say 
nothing about how to solve a problem in general. 

This is due to a number of factors, such as the problems of simply 
getting students to write correct solutions, as well as the difficulty 
of presenting the concepts involved in structured programming in a 
large lecture environment. A near-ideal situation might be for each 
student to construct his solutions in a one-on-oue tutorial environ- 
tttent, enabling him to receive correction of logical errors and comments 
on good programming practice as he goes along. There is Just not enough 
individual attention of this sort in the typical system of using teach- 
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ing assistants mid graders in conjunction with large lecture sections. 
Consequently, most students are never able to develop problen solving meth- 
ods ^ich result in vell-atructured solutions. 

Previous attempts at developing machine tutors of prograioaing I i», 5,7,10] 
liave not filled this need, primarily because of the sis^ae problem exampleB 
they are concerned with and their inability to provide useful ccouaents on 
the student's problem solving technique, as veil as his particular solution. 

ThXa pa];^r discusses an aut(»iatic tutor of programming, implemented on 
the PLA!ro IV CAI system [l] as a part of an automated instructional system 
for computer science being developed at the University of Illinois [8]. 
This tutor exposes the intraiuctoiy student to structured prograsmting 
concepts and top-down problem solution techniques by s^ans of example. 
The student develops (on-line, using an approach baaed on stepwise refine- 
ment [ 11]) a solution to a single, relatively conplex programming prob- 
lem (symbolic differentiation of a polynomial)- Student and tutor engage 
In an interactive dialogue during this problem-solving process, the tutor 
providing hints regarding solution steps, and ccmnents about program struct- 
ure and efficiency, A saiall sample of the typea or responses the tutor 
jnli^t make is presented in Fig. 1. 

Tutor's knowledge of solutions 

Clearly, for the tutor to provide meaningful comments and assistance to 
all students, it must possess a detailed knowledge of the solution space for 
the particular problem with which it is concerned. )ur tutor utilizes an 
AND-OR graph (Pig. 2 is a small portion) as a representation of all reason- 
able correct approaches to the particular problem, as well as many of the 
wrong approaches introductory students are likely to attempt. 

An OR node represents a point in the development of a solution where 
there are several (equally correct) acceptable approaches, and the student 
m^ continue a correct solution by following any of the branches out of the 
node. An AND node, on the other hand, represents a point at which there are 
several tasks which must all be done in order for the solution to be correct, 
and the student must traverse all brwichos out of the node to achieve a 
correct solution. 
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Tutor: Tell joe how you intend to proceed. 

[The tutor's standard pxts^] 

Student: I don* t. know. 

T$ Try to think of a vay to break the problem Into singpler sUbproblems. 

[A gentle hint for an AlfD node. There 
are several levels of hints for both 
types of nodes] 

Si Look for any special cases, 

Ts <HC, I«t»s call this task 1, 

S: Then consider the general case, 

Tj ok. het^B call this task 2, 
Moir let's consider task 1. 
Tell m how you intend to proceed. 

Ss I want to see if the derivative is zero, 

T: OK. Let's call this task 1.1, 

[A refinement at an AND node] 

« 
« 

Tj Tell me how you intend to proceed, 

[See Fig. 2] 

Sj I'm going to loop through the terra looking for what I'm differentiating by. 

[This input catches an error branch] 

Tj Try using built-in functions instead, 

[So the tutor displays the explicit hint, 
but the current node remains unchanged] 

Sj Maybe I want the INDEX function, 
T: OK, 
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Branches between nodes are associated with English phrases or prot^raa- 
ming language statements which the student awst eater to traverse the graph. 
The next node in such a traversal is selected by the tutor based on the ciu-- 
rent node type and the student's inputs. Branches may be regular branches, 
traversed in response to correct steps in a probl«a solution, or error branch- 
es, which lead to detailed remedial coBsoents which are presented to the student. 

Bote that such a graph represents all aspects of a problem solution. A 
path through the graph traces the refineiaent process the student went through 
in developing a solution, and the tip nodes, or acre properly, the prograiaaing 
language statements associated with the branches leading to the tip nodes , 
represent the actual program \^iQh solves the problen. This representation is 
auite similar to the decision structure noted by Ells and Freeman [3] in a 
review^ of the design process of several large software projects. 

The claim of being able to represent all reasonable solutions to a problem, 
as weU as a few wrong approaches, as an AND-OR graph clearly requires some 
Justification. Intuitively, one feels that the number of possible solutions 
must increase enormously as the complexity of the problem increases. Undotibt- 
edly, this would be true if we were considering every correct solution; how^ 
ever, we are considering only "good" solutions, which makes an important dif- 
ference. Many of the possible. solutions (especially the oolution's proposed 
Igr introductory students) may be immediately rejected on the basis of "good- 
ness". Thus paths representing inefficient or poorly structured solutions 
need not be included in the graph, even though such solutions may be correct 
in a strict sense. At most, such solutions will be one of the plausible 
wrong approaches. Further, the use of a graph form, as opposed to a tree, 
allows maximum common utilization of sub-portions of the graph. These factors 
significantly reduce the number of nodes the solution graph must contain, and 
enable us to use such a representation. 

Student-tutor interaction 

The existence of a natural language, interactive dialogue between student 
and tutor is an essential part of our tutoring system. It is through this 
medium that the student indicates the refinements to be made in achieving a 
problem solution, and that the tutor provides hints and ccHmsents, and controls 
the traverciil of the nolutloti (trnph. 



The riATO IV author laiitMOfie, TITTOR, provides a facility for dialofiuo 
control which is essentially a simple keyword parsing scheae {see [9] for 
details). lo general, such a scheB» is not adequate for conducting a nat- 
ural language discourse; however , the rigid local context provided by the 
current position in the solution graph (the only relevant inputs are assoc- 
iated with branches leaving the current node) limits the inputs the student 
might aake, and allows our tutor to "understand" the input and natch a branch 
In the solution graph a large percentage of the tiae. 

It is unlikely, of course, that suecesive student inputs will fallow 
exactly the sequence expected by the solution graph. At any given node, 
soae of the meaningful student inputs will match branches leaving that node, 
some will coalesce several levels of the solution graph into a single input, 
and some will a»tch single branches at a greater depth into the graph. 
Inclusion of all possible student inputs in the solution graph would cause 
a tremendous increase in the nua&er of branches leaving any node. Instead, 
we have chosen to inclixde only the most likely student inputs, based on 
observation of students solving the problem, and the tutor conducts a 
depth-first search of the solution graph in the vicinity of the current 
node, attes^ting to match the student input to a branch further down 
the graph. Depth of the search is controlled by information on the aver- 
age number of levels spaamed by the student's previous inputs. 

The tutor assigns **task names** to refinement steps as th^ are input by 
the student, based on the type of the current node in the solution graph. If 
the current node is an AND, several tasks will replace the old one, and an 
additional digit is added to the task name tor each new task. That is, 
1.2 figure total cost 

bec(»nea 

# 

1.2.1 subtract trade-in 

1«2.2 add sales tax 
On the other hand, if the current node is an OR, the new task sicq^ly replaces 
the old one, and the task name Is unchanged. The student may preface each 
task name with an identifying letter if he so desires. 

Task names are inqportant for several reasons. Perhaps the most important 
is that they provide an easy and precise way for both the student and tutor to 
identify a particular task. Thus the tutor can display a '*now refining 
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" message so the student is always sure which task is being discussed, 
and the student can refer to tasx nosies in his input. This could be accoi»» 
plished \/y siiaply using line nui^rs on the screen, but task nas^s have the 

added advantage of indicating the history and relationship of statements, 
without making the underlying solution graph explicit. That is, statements 

3.1.2 and F. 2. 3.1. 3 are brothers, having only recently been derived from 
a cramon father. On the other hand, tasks 3*2 and k*l have no eosaaon history. 
Cries [6] recc^ends use of indentation to indicate the relationship between 
various tasks described in the step-vise refinement process. However, on a 
m^um with a limited extent in both horisontal and vertical directions (such 
as the PIATO IV plasr- panel), the use of task names indicates task relation- 
ships Just as clear.. i^ile simplifying the screen management problem. 

Conclusion 

• 

It is generally agreed that introductory programming courses are not 
sufficiently concerned with teaching problem^solvihg methods and structxired 
progrttaottitig concepts* One way for students to leaim these ideas is by rol«< 
lowing exsmple problem solutions, but there are seldom enough teachers or 
graders available to provide such personal attention. Under these conditions, 
a CAI tutorial system which uses an interactive dialogue to guide a student 
through a top-down solution to a complex programming problean becomes an 
attractive idea* This paper has discussed one such system. 

The heart of the system is an AUD-OR graph representing both the student's 
solution process and the solution program for a cc»!^lex problem. Student and 
tutor traverse this graph in the process of solving the px^blem* There is a 
great deal of effort involved in developing ai^ch a solution graph for a sizable 
problem. However, such a representation provides several advantages which 
make the effort worthwhile, namely: 

(1) it allows the tutor to effectively engage in a natural 
language dialogue using a simple parsing scheme. 

(2) it enables the system to provide detailed comments on 
both the student's solution and his problem solving 
techniques* 
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(3) 'it allows such a machiue tutor to deal with ratht^ large 
problents, providing rlditional empfaasis of the need for 
good prograa structura and proper problem solving methods. 
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